Subject: Comments on IBM's Response to Public DataNet Routing Concerns

From: "jim (j.) cobban" <[email-masked]>
Date: Fri, 2 Jun 1995 15:53:00 -0400

One introductory point:  I can understand wanting to carry on the discussion
in only a single mailing list.  However few if any of the points which I am
raising are specific to ATM.  It also happens that I have not yet got my
name on the ATM mailing list.  I just sent in the subscription today.  I
retrieved IBM's comments from the archive.

Marcia Peters writes:

>o  We interpret your statements on ingress priority/delay scheduling
>   slightly differently:
>
>   We hear customers framing their needs in terms of requirements, not
>   solutions.  For example, our customers require separation of batch
>   and interactive traffic.  (This is an example, not an exhaustive
>   requirement list.)  They desire to use lower-cost facilities for
>   batch, or to limit the use of high-cost facilities to time-critical
>   interactive and transactional traffic.  If facilities are shared
>   among different traffic types, at times when the offered load exceeds
>   the engineered network capacity, they want time-sensitive traffic to
>   be delivered preferentially.  Traffic that is not time-critical has
>   been designated as batch and can be delayed.

I naturally express my requirements from the point of view of a network
provider, rather than a network user.  That does NOT mean that I am
expressing solutions (except where explicitly noted) rather than
requirements.

Our customers have phrased their requirement as being able to extend
priority and class of service to the underlying switched data network.
In particular they demand that at each node in the switched data network
high priority SNA PIUs must be permitted to overtake low priority PIUs.

>   In any event, there are several ways to accomplish this:
>
>   -  Your suggestion is to implement layer 3 priorities in a
>      multiplexed layer 2 service.  Actually, there is nothing to
>      prevent a switch vendor from peeking into COS/TPF on an APPN BIND
>      if you have some way to support this type of priority mechanism in
>      your switches (but I doubt that how you customize your switches is
>      a topic of COMMON interest to AIW members).
>
If the switch peeks into COS/TPF on the BIND then it effectively becomes a
LEN node, rather than a switch.  The fact that something is technically
feasible does not necessarily mean that it is practical or economical.
We have examined this option and concluded that it is neither.

>   -  We prefer a different model: we prefer giving the layer 3
>      transport the option to set up multiple layer 2 VCs with
>      appropriate traffic contracts (bandwidth) and QoS.  Then without
>      customizing layer 2 for specific layer 3s, APPN (or any other
>      intelligent layer-3 transport) performs mappings itself.  In this
>      model, a subnet is strictly a service provider and APPN is a
>      strictly a service consumer, according to a standard-specified
>      interface (e.g., ATM Forum, ITU-T, ISO...)

The concern that I have with this is that APPN itself must change to deal
with each individual underlying layer.  If APPN had a history of rapidly
adapting its link support capabilities to the available data link
capabilities, then you might be right.  However the facts tell us that
despite many years of effort APPN still only supports SDLC serial links and
Token-Ring LANs.  If an underlying network does not look like either of
those two, then it is effectively crippled.  

Consider a related example.  Operating systems, such as OS/2, do not have
detailed support for each type of disk drive, or each type of display
adapter.  They simply define a generic interface, and it is the
responsibility of the hardware vendor to supply the device driver.  As a
vendor of data link layer networks, Nortel would like to be able to supply
APPN "device drivers" which would provide access to all of our capabilities,
without constantly demanding that the APPN routing architecture itself be
modified.

>      Actually, since tariffs and fixed equipment costs differ so vastly
>      across geographies, we think it better to give customers a lot of
>      flexibility in how they set up layer 2 services to meet layer 3
>      requirements.  Where per-circuit charges are low, customers might
>      want to provision (or dial up) several VCs with different QoS for
>      APPN's use, with much granularity; where per-circuit costs are
>      high, they might prefer having APPN mux all priorities onto a
>      single circuit.

>      To provide this flexibility requires some extensions to the LAN
>      connection network model.  First off we MUST remove the
>      restriction of one TG per port per CN.
>
Your final statement is arguable, since it is conditioned upon the
assumption that prioritization must be performed at layer 3.  You have just
pointed out a weakness of that assumption in the last sentence of the
previous paragraph.  There may be value in supporting more than one TG per
port per CN but that requires further discussion.

>      Please think of the LAN connection network model as a special case
>      of a generalized connection network framework.  The generalized
>      framework allows >1 TG/port/CN.  The ONLY reason for LAN CN's 1
>      TG/port/CN restriction was because, ON A TOKEN RING, multiple
>      connections have no advantage: the T/R MAC itself provides
>      fairness to all users, despite single or multiple connections.
>      The restriction makes no sense for FR, X.25, or ATM.

You are forgetting that TRN supports priorities, and therefore there is the
opportunity for violation of fairness.

>o  Our viewpoints appear to diverge further at paragraphs 9-10:
>
>   While we agree on the desirability of minimizing TDU traffic and TDB
>   size, zero change to the LAN CN model and to SS/TRS is not an absolute
>   requirement.  In fact, we believe we have a way to meet the customer
>   requirement articulated above without materially changing SS or TRS.
>
>   We specifically disagree with your statement "It is desireable to
>   leave <the question of mapping APPN priorities to one or more VCs> to
>   the underlying network, rather than modelling it in APPN."
>
>   Most SNA networks today are private networks that incorporate some
>   public switched services.  Private networks BY DEFINITION are
>   unwilling to rely solely on a single carrier.  A given APPN backbone
>   node will usually have >1 link for availability reasons, and often
>   the link types are different.  Thus your proposal to move VC
>   selection to the DLC is unacceptable, since it would remove much of
>   APPN's value.  DLC is not in a good position to select the route,
>   since it can't know what other connectivity the node may have.
>
I do not entirely understand this argument.  By the time that APPN requests
the establishment of a VC, all of the route determination that APPN is
capable of doing has already been done.  APPN has already decided that the
best route for this connection is across the specific port.  All that I have
suggested is that we not hamstring the underlying public data network by
denying it access to information about the required quality of service by
keeping that information private to APPN.  The DLC cannot make a good choice
of route, within the public network, if it is not provided with that
information.

>   Some form of passing signalling to and thru the DLC may be useful,
>   but ONLY IF APPN CAN FIRST BE MADE TO PICK THE RIGHT ADAPTER AND
>   LINK.  The existing RSS algorithm does this well, as long as the
>   subnet is characterized in terms of TG characteristics.  That is,
>   APPN needs a standard set of metrics to compare one TG with another.
>   We believe the current TG characteristics are adequate for this since
>   they are quantitative (e.g., actual propagation delay, capacity, cost
>   per byte, etc.)
>
The current RSS algorithm does NOT do this very well.  The existing
algorithm will consistently put BATCH traffic on the same VC with INTERACT
traffic even when our customers do not want that to happen.

>   What is deficient, however, are the current COS tables.  We noticed
>   that the COS tables are oriented towards 1980s-vintage link speeds
>   and error rates.  They lack sufficient granularity at high speeds.
>   We think it would be a good idea to add some rows to the COS table to
>   remedy this.  This is not urgent, but it would be good to do in the
>   same time frame when products add native ATM CN support.

I do not believe that this problem is solvable in the way that you have
suggested.  I have tried modifying the COS tables with their existing
metrics in numerous ways and I cannot get them to unequivocally select a
high priority virtual circuit for INTERACT and a low priority virtual
circuit for BATCH.  Until you can prove otherwise it is my contention that
the RSS algorithm is broken.  Even if you can prove your contention, is it
reasonable to demand that everyone replace their existing COS tables to fix
the problem?  It is conceivable that IBM may have enough pull with their
customers to force this through, but I seriously doubt that any APPN user
is going to pay any attention if Nortel tells them they have to replace their
COS tables in order to be able to use our networks.  Therefore no solution
to the requirement to extend priority and class of service routing into the
underlying network is acceptable to Nortel unless it can be done WITHOUT
modifying the COS tables.

>o  Finally, we agree APPN should not perform unnatural acts to
>   accommodate weirdly-engineered CUGs.  For X.25, mapping each CUG to
>   a different CN appears to be a good idea.
>
>o  Signalling
>   I have not yet reviewed this part of the proposal in detail.
>   We'd like your reactions to the thoughts expressed above first.
>
>o  In addition I'd like to respond to some concerns you raised verbally
>   during the meeting:
>
>   - One subject was how the APPN CP learns about transmission
>     facilities that are available to it.  APPN architecture models this
>     in terms of system definition of certain parameters to NOF.  You
>     were concerned that the APPN CP not try to manage multiprotocol
>     facilities of the whole node.  We agree.  Implementations will
>     differ in where and how such parameters are obtained.  For example,
>     a multiprotocol node might have a configuration utility to set up
>     the whole node.  Whatever node resources are assigned to APPN could
>     perhaps be passed to the APPN CP as NOF input parameters.  These
>     are not architectural issues.

I am certainly doing this with our current implementation.  The problem we
run into is that we cannot issue the NOF definitions until the actual
logical interfaces (for example VCs) are available for us to interrogate.
The result is that the logical interfaces are not visible from APPN until
the metrics are available.  If I could define the logical interface from
above, and then learn the metrics from below, that is from the DLC, then
this management issue would vanish.

There is also no mechanism by which the metrics can be adjusted on the fly
as the characteristics of the network change.

>     What IS an architectural issue, however, is the need for all APPN
>     nodes to use consistent metrics to express TG characteristics,
>     especially effective capacity.  We need an architecture that says
>     specifically how APPN capacity is set in the following cases:
>
>       (1) reserved bandwidth,
>
>       (2) best effort service
>
>       (3) VC shared with other protocols:
>
>            (3a) if the queuing system allows APPN to use all of
>                 the VC's capacity when the other protocols are idle
>
>            (3b) if the queuing system does not allow APPN to use all of
>                 the VC's capacity when other protocols are idle.
>
>     Consistent capacity reporting methods are needed, in order to meet
>     customers' requirement for consistent behavior of APPN's route
>     selection algorithm.

I presume that your concern here is that existing implementations report a
fictional effective capacity which is not necessarily closely related to
the actual capacity of the TG in question.  This is particularly challenging
with respect to public networks.  What exactly is the "effective capacity"
of a particular virtual circuit going over a complex chain of nodes and
trunks?  As I have mentioned elsewhere what happens if the capacity of a
shared facility changes on the fly as a result of other activities on the
link?

>   - We didn't understand exactly what you meant about passing
>     signalling to DLC.  By 'signalling' do you mean the information
>     defined in, e.g., Q.2931?  Or does 'signalling' refer to parameters
>     such as layer 3 priority information?  Did you mean at link
>     establishment, or on each data packet?  One of us thought you
>     proposed sysdef'ing setup parameters to DLC and then passing
>     priority ON EACH PACKET; was that your intent?

The highest priority for us is signalling the layer 3 priority on each
DLC_MU packet passed from PC.  This information is available in HPR, but not
in ISR.  There would be some internal system definition inside the DLC which
tells it how to interpret the SNA level priorities.

I believe that what should be signalled to the DLC is generic information
which is meaningful to APPN, but useful to the DLC.  I do not believe that
we should signal Q.2931 type parameters unless those parameters have a
direct relationship to something in APPN.

>   - Another person thought you wanted DLC to be able to establish
>     multiple SVCs per link.  Was this your intent?

They are both right.  The SNA level priority is only useful to the data link
layer if it is capable of applying it.  The meaning of "applying" will
depend upon the capabilities of the data link layer.  In the case of X.25
and Frame-Relay each virtual circuit only has a single priority, since the
definition of those services demands that all data packets be delivered to
the far end in the same order in which they were received.  Therefore the
only way that an X.25 or Frame-Relay DLC can implement priority is by
establishing multiple VCs with different priorities.  In the case of other
data links there may not be any VC equivalent. 

>We'd appreciate clarification of these points and any others we may
>have misunderstood.
>
>Marcia Peters ......................... IBM Corp., APPN Architecture Team

Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcars153!jcobban       |  FAX:   (613) 763-5199
|                                                                             |
|   The opinions expressed are those of the author and do not necessarily     |
|   represent the opinions of Bell-Northern Research or Northern Telecom.     |